Traditional mobility support aims to provide continuous Internet connectivity to mobile hosts; thus offering host mobility support. In contrast, network mobility support is concerned with situations where an entire network changes its point of attachment to the Internet topology and thus its reachability in the topology. Such a network in movement can be called a Mobile Network.
There exist a large number of scenarios where such Mobile Networks exist. Two out of many examples are:                A Personal Area Network (PAN, i.e. a network of several personal devices attached to an individual) changing its point of attachment to the Internet topology while the user is walking in a shopping mall.        A network embedded in a vehicle, such as a bus, a train or an aircraft providing on-board Internet access to passengers. A passenger may use a single device (such as a laptop computer) or own a Mobile Network (such as a PAN), which then illustrates a case of a Mobile Network visiting a Mobile Network (that is to say nested mobility).        
As such, a Mobile Network can be defined as a set of nodes (so called Mobile Network Nodes or MNNs) forming one or more IP-subnets attached to a Mobile Router (MR), the Mobile Network (the MR and all its attached MNNs) being mobile as a unit with respect to the rest of the Internet. Internet-Draft draft-ernst-monet-terminology-00.txt [Thierry Ernst, Hong-Yon Lach, “Network Mobility Support Terminology”, draft-ernst-monet-terminology-00.txt, February 2002, work in progress] defines terminology for Mobile Networks that will be used in the following. Especially the following terms are defined:                Local Fixed Node (LFN): A node permanently located within the Mobile Network and that does not change its point of attachment. A LFN can either be a LFH (Local Fixed Host) or a LFR (Local Fixed Router).        Local Mobile Node (LMN): A mobile node that belongs to the Mobile Network and that changes its point of attachment from a link within the mobile network to another link within or outside the Mobile Network (the home link of the LMN is a link within Mobile Network). A LMN can either be a LMH (Local Mobile Host) or a LMR (Local Mobile Router).        Visiting Mobile Node (VMN): A mobile node that does not belong to the Mobile Network and that changes its point of attachment from a link outside the Mobile Network to a link within the Mobile Network (the home link of the VMN is not a link within the Mobile Network). A VMN that attaches to a link within the Mobile Network obtains an address on that link. A VMN can either be a VMH (Visiting Mobile Host) or a VMR (Visiting Mobile Router).        Mobile Network Prefix: A bit string that consists of some number of initial bits of an IP address which identifies a Mobile Network within the Internet topology. Nodes belonging to the Mobile Network (i.e. at least MR, LFNs and LMNs) share the same IPv6 “network identifier”. For a single mobile IP-subnet, the Mobile Network Prefix is the “network identifier” of this subnet.        Egress Interface of a MR: The interface attached to the home link if the Mobile Network is at home, or attached to a foreign link if the Mobile Network is in a foreign network.        Ingress Interface of a MR: The interface attached to a link inside the Mobile Network.        
Whereas the draft Mobile IPv6 specification [D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6””, draft-ietf-mobileip-ipv6-20.txt, January 2003, work in progress] defines two means for a Mobile Node to receive multicast traffic while on the move, namely bi-directional tunnelling and remote subscription, only the bi-directional tunnelling approach is currently foreseen in the case of a Mobile Network. In fact, most advanced proposals rely on bidirectional tunnelling between the Mobile Router and its Home Agent through which unicast and multicast traffic of Mobile Network Nodes should be forwarded in both directions. Especially in the case of multicast traffic:                Inbound multicast packets for MNN (i.e. multicast packets addressed to a multicast group G to which MNN has subscribed—MNN is a multicast receiver) are routed along the multicast tree in the backbone towards the Mobile Router's home link; intercepted by the MR's Home Agent HA that tunnels them through a unicast tunnel to the MR, de-tunnelled by MR and forwarded along the multicast tree within the Mobile Network, and finally received by MNN as shown in FIG. 1 of the accompanying drawings.        Outbound packets (i.e. multicast packets sent by MNN to a multicast group G—MNN is a multicast source) are routed towards the Mobile Router, reverse-tunnelled by MR to its Home Agent HA, and from there routed towards the multicast delivery tree as shown in FIG. 2.        
This mechanism does not provide route optimization to the MNNs since multicast packets between the multicast delivery tree (in the backbone) and the MNN must go through the bi-directional tunnel between MR and HA, which potentially introduces a much longer path (take as illustrative example a MR deployed in a plane flying over the USA while its HA is located in France).
Thus there is a need for a means to enable MNNs to receive multicast traffic along an optimized path, that is to say, to have packets delivered through the multicast tree to or from the current location of the Mobile Router without needing to transit through the MR Home Agent HA.
US Patent specification 20020150094 proposes a new IP multicast routing protocol, called “Hierarchical Level-based IP Multicasting” (HLIM) which is said to support not only host mobility (movement of IP hosts) but also network mobility (movement of IP routers with or without attached hosts). Especially, HLIM is claimed to preserve on-the-shortest-path delivery of multicast traffic from a source to a receiver located within a mobile network as the network changes its attachment point in the topology. However, HLIM, which has been designed for tactical networks, can only operate in very specific network topology (hierarchical networks), which is not the case of the Internet, thus limiting its applicability for commercial applications. In addition, HLIM requires all routers in the topology to run this new protocol which is unrealistic in the Internet whose multicast model is based on many multicast domains (owned by different parties) and possibly running different multicast protocols (such as DVMRP, MOSPF, PIM-SM, PIM-DM, CBT, for example). Thus HLIM does not provide a means to support route optimised delivery of multicast traffic to a mobile network roaming in the Internet, irrespective of the multicast routing protocols used within and outside of the mobile network.
It is not desirable for a Mobile Router to rely on relaying multicast routing signalling messages (used to manage the multicast tree) between the nodes in the mobile network and the visited network (instead of through its home network and its Home Agent HA) in order to reconstruct a branch of the multicast tree towards the current location of the multicast-enabled mobile router. This approach is applicable if and only if the same multicast routing protocol is run both within the mobile network and visited network. As explained above, due to the very large number of existing multicast protocols, this requirement will rarely be met in practice. As a result, this approach does not enable route-optimised delivery of multicast traffic irrespective of the location of the mobile network in the Internet. In addition, in practice, security policies of the visited network will generally forbid any injection of routing signalling (unicast and multicast) from non-authorized nodes such as a visiting mobile router (the mobile router may be owned by a different organisation).
It has been proposed that the Mobile Network deploy on all routers within the mobile network a mechanism called “IGMP/MLD-based Multicast Forwarding” [B. Fenner, H. He, Nortel Networks, B. Haberman, H. Sandick, “IGMP/MLD-based Multicast Forwarding (“IGMP/MLD Proxying”), draft-ietf-magma-igmp-proxy-02.txt, March 2003, work in progress] instead of running a multicast routing protocol internally. This approach is intended to allow the Mobile Router to collect all multicast group membership information coming from within its mobile network, and subscribe itself to all those multicast groups using IGMP/MLD protocol with the multicast-enabled access router in the visited domain. Group membership information will be relayed hop-by-hop, in the mobile network, from the intended multicast receiver up to the Mobile Router, by means of all intermediate fixed routers proxying incoming IGMP/MLD Report messages received towards its parent router (this is known as IGMP proxying, or MLD proxying). In this approach, the Mobile Router handles the multicast subscription in the visited domain on behalf of all the nodes in the mobile network. Upon movement, it will trigger reconstruction of a new multicast branch at its new location by sending MLD Reports to its new attachment point. However this approach requires heavy manual configuration, in particular to define upstream and downstream interfaces, on each router in the mobile network to make its internal topology like a tree routed at the Mobile Router. This makes this approach applicable only for relatively small mobile networks with stable internal topology. In addition, it imposes deployment of a new forwarding mechanism (IGMP/MLD proxy) on each internal router, and does not support route-optimised delivery of multicast traffic for any other form of multicast routing deployed in the Mobile Network. This is a limitation, especially for large mobile networks where regular multicast routing protocols are expected to be deployed to ease multicast support within the mobile network.
Thus there is a need for a mechanism enabling route-optimised delivery of multicast traffic to and from a mobile network:                irrespective of the location of the mobile network in the Internet,        irrespective of the type of multicast routing protocols used within and outside of the mobile network, and        through extension of the Mobile Router involved alone, that is to say with no change to any node in the mobile network nor in the Internet.        